SET.Subject is typed subjectid.SubjectIdentifier, an interface whose
dynamic type depends on how the SET was built. Parse delegates sub_id to
subjectid.Parse, whose registry constructors return pointers, so a parsed
SET carries the pointer form (*subjectid.IssSubID). A SET built in Go
naturally holds the value form (subjectid.IssSubID), because the concrete
types satisfy the interface with value receivers. The result is an
asymmetric round-trip: a consumer writes IssSubID{} but reads back
*IssSubID, and the obvious assertion set.Subject.(subjectid.IssSubID)
silently takes the !ok branch after a parse and drops the event. It is the
kind of bug that passes a hand-built unit test (value form) and fails on
real wire input (pointer form). A downstream Shared Signals consumer hit
exactly this.

SubjectAs[T] absorbs the distinction once for all consumers: it tries a
direct assertion to T (the value form) and, failing that, peels a single
pointer indirection via reflection to match the pointer form, returning
the value either way. A type assertion to *T will not compile for an
arbitrary type parameter, so the pointer case goes through reflect; the
nil-pointer guard keeps reflect.Value.Elem from panicking on a typed nil
in the interface. IssSub is the non-generic shorthand for the
overwhelmingly common iss_sub format. The SET.Subject godoc now states the
parsed dynamic type so the asymmetry is discoverable from godoc alone.

This is the non-breaking, consumer-side half of the fix. Normalizing the
canonical form in go-subjectid's Parse is a wider, possibly breaking
decision and is tracked separately.

Tests cover the value form, the pointer form, the absent / nil-receiver /
typed-nil / wrong-format misses, and the acceptance round-trip
(SET{Subject: IssSubID{...}} through Encode and Parse back to an equal
IssSubID via the accessor). A runnable ExampleSET_IssSub documents the
parse-then-read flow. No wire-format change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>